In 3GPP radio access technologies, a network decides when the mobile device shall handover from one cell to another cell. The network makes that decision based on radio measurement reports that the network requests from the mobile device and potential other information that is available to the network. A number of activities are ongoing to integrate WLAN with the 3GPP architecture. In the latest specification 3GPP Rel-11, this integration is still fairly undefined and the decision when to handover between 3GPP radio access and WLAN is left to the mobile device. Work is ongoing now to change this integration by letting the network decide when to handover between 3GPP and WLAN. When the network decides such an offload step, it also needs to decide what portion of this mobile device's traffic to handover. That is some traffic may stay at the source access, and some traffic may be moved to the target access. The terms “handover” and “offload” may be used interchangeably.
Fixed-Mobile Convergence (FMC) is a trend that has been on-going for many years now. The overall aim of FMC is to provide a seamless user experience (i.e., a particular service can be used anywhere at any time). The user is not troubled where the service is located or via which access technology the service is reached at a particular point in time. In the last few years efforts on FMC have mainly focused on integration of WLAN (Wireless Local Area Network) with 3GPP (3rd Generation Partnership Project) technologies. The vision is a heterogeneous network, where WLAN is integrated into the 3GPP Evolved Packet Core (EPC) just like any other cellular radio-access technology (RAT). See Achieving carrier-grade Wi-Fi in the 3GPP world, Ericsson Review, 2012.
Some of the key drivers for the integration of WLAN with 3GPP are: a) The large growth in mobile broadband traffic. To accommodate this, the unlicensed WLAN spectrum can serve as a complement to the 3GPP RAT spectrum; b) The wide support of WLAN in devices. Most modern mobile devices include both 3GPP radio and WLAN radio; c) The desire from operators to support the same services regardless access.
A 3GPP UE (User Equipment, a mobile device) can attach to a non-3GPP access network (e.g. a WLAN access network) and get connected to one or more PDNs (Packet Data Networks) via the S2 interface. See Achieving carrier-grade Wi-Fi in the 3GPP world, Ericsson Review, 2012. Each PDN connection is anchored in a 3GPP PGW (PDN GateWay). The UE receives one IP address/prefix for each PDN connection. It is the PGW that assigns the address/prefix. The S2 interface comes in three flavors: S2a, S2b and S2c. The latter two overlay the non-3GPP access network and do not impact it. S2a is a more converged solution that does impact the non-3GPP access. FIGS. 1 and 2 describe the concepts PDN, PGW, SGW, PDN connection, EPS bearer, TWAG, AC and AP. See also 3GPP TS 23.402, Architecture enhancements for non-3GPP accesses. Particularly, FIG. 1 shows how bearers and PDN connections work over a 3GPP radio access. In a WLAN access network, only a subset of this is supported today in Rel-11, which is illustrated in FIG. 2.
One of the 3GPP work items in this area is SaMOG (“Study on S2a Mobility based on GTP & WLAN access to EPC”) 3GPP TR 23.852, Study on S2a Mobility based on GTP & WLAN access to EPC (SaMOG). The aim of SaMOG is to allow a UE to gain access to the 3GPP EPC using WLAN as access technology. The SaMOG study is performed in two phases. The first phase has already been finalized and released as part of 3GPP Rel-11. The result is captured in 3GPP TS 23.402, Architecture enhancements for non-3GPP accesses section 16.2. The first phase of SaMOG provides only a limited functionality, where no handover with IP address preservation between 3GPP and WLAN is supported. Also, the UE is restricted to have only a single PDN connection or a single offload connection via WLAN. The latter is used if an operator decides to offload the EPC in situations where an offload connection is setup. The UE's traffic is then not routed via EPC, but from the WLAN access network directly offloaded to Internet. This is contrary to a PDN connection that is always routed via EPC.
The second phase of SaMOG is ongoing. Two main scenarios are being studied as part of the second phase. The first scenario, “single-PDN scenario”, is a small extension to the Rel-11 baseline with added support for IP address preservation upon a handover between 3GPP and WLAN. The second scenario, “multi-PDN scenario”, includes not only support for handover with IP address preservation, but also support for multiple PDN connections via WLAN, and support for having one or more PDN connection via 3GPP simultaneous with one or more offload connections via WLAN. FIGS. 3 and 4 illustrate how a UE attaches to WLAN. This is a simplified copy of the call flow in 3GPP TS 23.402, Architecture enhancements for non-3GPP accesses section 16.2, with block 6 and handover support added as described in, for example, the single-PDN scenario in SaMOG 3GPP TR 23.852, Study on S2a Mobility based on GTP & WLAN access to EPC (SaMOG). It is noted that FIG. 3 shows the GTP option. PMIP is possible well, as described in 3GPP TS 23.402, Architecture enhancements for non-3GPP accesses.
FIG. 4 illustrates a simplified copy of the multi-PDN scenario in SaMOG 3GPP TR 23.852, Study on S2a Mobility based on GTP & WLAN access to EPC (SaMOG). In this example, the first connection is an offload connection. Attachment parameters for the first connection are sent as part of authentication (step 2). A second connection, a PDN connection in this example, is setup in block 5. The term “handover” used herein, in most cases, refers to handover between 3GPP access and non-3GPP access as defined in 3GPP TS 23.402, Architecture enhancements for non-3GPP accesses.
The SaMOG study defines how a UE attaches to the network, and in particular, how a PDN connection is setup via WLAN. The study does not specify which AP the UE attaches to. Neither does it specify under which conditions the UE can attach to a specific AP. On a high level, there are two methods to control a UE when to attach, and to which AP.
The first method is based on policies in the UE. These policies may be pre-configured in the UE, or may be downloaded from a network node. In a 3GPP architecture, such network node is called Access Network Discovery and Selection Function (ANDSF). A policy rule may e.g. say “Attach to SSIDx when it is available”. Work is ongoing to further extend and refine the ANDSF policies. An example of such refined rule is to include performance measurements like “Attach to SSIDx only when the load of the AP is below a certain threshold”. Such work is performed in 3GPP in the study “WLAN Network Selection” (WLAN_NS) 3GPP TS 23.865, WLAN Network Selection for 3GPP Terminals; Stage 2. Similar work is performed within Wi-Fi Alliance and their HotSpot 2.0 program Wi-Fi Alliance HotSpot 2.0.
In the second method, it is the network that decides when and where the UE shall attach. It then instructs the UE to do so by an explicit command. This way, policies are kept inside the network. The network mobility function may make its decision based on measurements performed by the UE (e.g., the UE may be attached to LTE). The network then instructs the UE to take measurements of the WLAN APs it sees. After receiving the measurement results, the mobility function decides which AP the UE shall attach to. Finally, the mobility function explicitly instructs the UE to attach.
FIGS. 5 and 6 define what IFOM (IP flow mobility) and MAPCON (Multi Access PDN Connectivity) is. See 3GPP TS 23.402, Architecture enhancements for non-3GPP accesses for a more detailed description.
Traffic steering from one RAT to another RAT may be triggered in different ways. While not critical for this invention some alternatives are explained below.
Traffic steering from one Radio Access Technology (RAT) to another RAT may be triggered in different ways. The network may initiate traffic steering of a UE's traffic by sending a traffic steering command to the terminal. The traffic steering command may contain an indicator which points to a bearer or group of bearers, for example, a bearer index indicating to the UE that the indicated bearer should be moved. Another indicator is a QCI number and the bearers with the indicated QCI should be moved. It may be so that if there is no indicator present in the traffic steering command the terminal will move all traffic. However, as explained in further detail below, the 3GPP RAN may not know which Packet Data Network (PDN) a bearer belongs to and hence, may initiate traffic steering which results in partial PDN connection offloading.
The 3GPP RAN may indicate to a terminal that a first bearer should be moved to WLAN without indicating that second bearer belonging to the same PDN connection should be moved to WLAN. In this regard, a problem exists in that it is not possible to have a PDN connection where one or more bearers of that connection go over radio access technology A and one or more bearers of the same connection go over radio access technology B. Thus, it is not possible to perform a handover of a single bearer within a PDN connection to another radio access technology. Instead, the handover needs to be done on the granularity of a PDN connection. More specifically, current specifications require that if a UE has multiple PDN connections to an Access Point Name (APN) X, then that complete set of PDN connections has to be routed over the same radio access. This implies that if the UE wants to handover a PDN connection to another radio access technology, then the UE should handover all PDN connections of that PDN to the other access technology. An APN may be a string representing the name of a PDN.
Traffic steering may also be initiated by the terminal itself. This can be initiated based on a rule in the terminal, e.g., that the terminal should initiate traffic from a first RAT to another RAT if the signal quality in the first RAT is below a threshold and/or the signal quality in the second RAT is above a threshold. The terminal may then initiate traffic steering to that other RAT. The terminal may only initiate traffic steering for a subset of the ongoing traffic, e.g. keep a voice connection in one RAT suitable for voice service and steer an FTP download session in another RAT which currently is providing higher throughput.
Thus, when an offloading is performed, for example from 3GPP to WLAN, all the bearers belonging to a PDN connection either have to be offloaded together to WLAN, or they have to remain with the 3GPP network. As mentioned above, even within the same PDN connection, some bearers might be eligible for offloading to WLAN and some might be not. Thus, when offloading is performed, the PDN connection can be moved to WLAN only in the case that all the bearers belonging to that PDN connection are eligible for offloading (hereafter by “moving a PDN connection”, it is meant that PDN connection is now access via the target network).
For the RAN to be able to perform a proper offloading, it has to know 1) the eligibility of all bearers for offloading and 2) which bearers belong to which PDN connection. Currently, RAN is not aware of the mapping of the bearers with PDN connections.